Ao lidar com os resultados encontrados nos testes, têm-se como principais objetivos: realizar avaliações resumidas contínuas da qualidade percebida do produto, identificar e capturar os resultados de teste detalhados e propor ações corretivas apropriadas para resolver defeitos na qualidade. Para tais ações uma sequência de passos é indicada:

1. Examinar todos os incidentes e defeitos do teste: Nesta tarefa, os relatórios de teste são analisados para determinar os resultados significativos em relação às diferenças entre os resultados esperados e os resultados reais de cada teste. Identifique e analise cada incidente e falha sucessivamente e obtenha uma noção detalhada dos problemas resultantes.
   O objetivo é aprender o máximo que puder sobre cada ocorrência, investigue incidentes duplicados, sintomas comuns e outros relacionamentos entre os incidentes. Essas condições normalmente permitem um insight valioso sobre a causa original de um grupo de incidentes.
2. Criar e manter controles de mudanças: O objetivo é inserir informações de controle de mudanças em uma ferramenta de controle para avaliação, gerenciamento e resolução, pois as diferenças indicam possíveis defeitos nos objetivos do teste e contém uma indicação das ações corretivas apropriadas a serem tomadas. Para tal realize os seguintes passos:
   • Verificar os fatos do incidente: Verificar se há dados precisos de suporte disponíveis, agrupe os dados para anexação diretamente no controle de mudanças ou indique onde esses dados podem ser obtidos separadamente. Sempre que possível, verifique se o problema é reproduzível. Os problemas reproduzíveis têm muito mais probabilidade de receberem a atenção do desenvolvedor e serem corrigidos subsequentemente; um problema que não pode ser reproduzido tanto frustra a equipe de desenvolvimento quanto desperdiça recursos valiosos de programação em uma pesquisa inútil. Recomenda-se que você continue registrando esses incidentes, mas tenha o cuidado de identificar os incidentes irreproduzíveis separados dos reproduzíveis;
   • Esclarecer detalhes do controle de mudanças: É importante que a descrição detalhada do controle de mudanças não seja ambígua e possa ser facilmente interpretada, convém registrá-la o mais rápido possível, mas separe um tempo para voltar nelas, a fim de melhorar e expandir as descrições antes que elas sejam visualizadas pela equipe de desenvolvimento. Forneça o maior número de sugestões de solução possíveis. Isso ajudará a reduzir qualquer ambiguidade que ainda exista na descrição e normalmente ajuda a esclarecer, também aumenta a probabilidade de que seja encontrada uma solução mais de acordo com suas expectativas. Além disso, mostra que a equipe de teste está preparada não só para localizar os problemas, mas também para ajudar a identificar as soluções apropriadas. Outros detalhes que você deve incluir são capturas de imagens de tela, arquivos de dados de teste, relatórios de teste automatizados, saída dos utilitários de diagnóstico e qualquer outra informação que possa ajudar os desenvolvedores a isolar e corrigir o erro subjacente.
   • Indicar a gravidade relativa do impacto e a prioridade de resolução: Forneça uma indicação para a equipe de gerenciamento e desenvolvimento sobre a gravidade do problema, em equipes maiores, a determinação da prioridade de resolução real é responsabilidade da equipe de gerenciamento; entretanto, você pode permitir que as pessoas indiquem sua prioridade de resolução preferencial e ajustem subsequentemente, conforme necessário. Como regra geral, recomenda-se que você atribua, por padrão, uma prioridade de resolução média para as solicitações de mudança, aumentando ou diminuindo essa prioridade em cada caso, conforme necessário, é importante que a equipe de gerenciamento saiba quando um defeito está causando impacto no esforço de teste e esteja ciente da gravidade para os usuários. É possível que um incidente seja realmente grave, como uma pane do sistema, mas as ações necessárias para reproduzi-lo têm pouca probabilidade de ocorrer. Nesse caso, a equipe pode indicar essa gravidade como alta e uma prioridade de resolução muito baixa.
   • Registrar controles de mudanças adicionais separadamente: Ao identificar e registrar uma mudança, você geralmente identifica outros problemas que precisam ser tratados. Evite a tentação de simplesmente incluir essas descobertas adicionais no controle de mudanças existente: se as informações estiverem diretamente relacionadas e ajudarem a resolver melhor o problema existente, então está OK. Se os outros problemas forem diferentes e você identificá-los em uma mudança existente, eles poderão não ser processados, poderão não obter a prioridade apropriada a que têm direito ou poderão causar um impacto na velocidade de tratamento dos outros problemas.
3. Analisar e avaliar o status: Calcular e fornecer as principais medidas e os indicadores do teste:
4. • Distribuição de Incidentes: Analise os incidentes baseado em sua distribuição, por exemplo, área funcional, risco de qualidade, testador e desenvolvedor atribuídos. Procure padrões na distribuição, como áreas funcionais que pareçam ter uma contagem de defeitos acima da média. Procure identificar se há desenvolvedores ou testadores que possam estar sobrecarregados e que estejam apresentando problemas de qualidade.
   • Cobertura de execução do teste: Para avaliar a cobertura de execução do teste, você precisa revisar os relatórios de teste e determinar a relação entre a quantidade de testes realizados neste ciclo de teste e o número total de testes para todos objetivo dos teste pretendidos e o número de casos de teste executados com êxito. O objetivo é garantir que um número suficiente de testes destinados ao ciclo de teste tenham sido executados de forma proveitosa. Se isso não for possível ou para aumentar esses dados de execução, um mais critérios de cobertura de teste adicionais poderão ser identificados, com base em: Risco de qualidade ou prioridade; cobertura baseada em especificações(requisitos etc.); prioridade ou necessidade de negócio e cobertura baseada em códigos.
   • Estatísticas de controles de mudanças: Para analisar defeitos, é necessário revisar e analisar as medidas escolhidas como parte da estratégia de análise de defeitos. As medidas de defeito mais comuns são (geralmente exibidas em forma de gráfico): Densidade de defeitos - o número de defeitos é mostrado como uma função de um ou dois atributos de defeitos (como distribuição por área funcional ou risco de qualidade comparado ao status ou à gravidade); tendência a defeitos - a contagem de defeitos é mostrada como uma função ao longo do tempo e tempo de permanência de defeitos - um relatório especial de densidade de defeitos em que as contagens de defeitos são mostradas como uma função do período de tempo que um defeito permaneceu em um determinado status (aberto, novo, aguardando verificação etc.). Você deve apresentar os resultados na forma de diagrama com as descobertas feitas para justificar a solicitação.
5. Fazer uma avaliação da experiência de qualidade atual: Formule um resumo da experiência de qualidade atual, realçando os aspectos positivos e negativos da qualidade dos produtos de software.
6. Fazer uma avaliação de riscos de qualidade iminentes: Identifique e explique essas áreas que ainda não foram abordadas em termos de riscos de qualidade e indique qual o impacto e o perigo resultantes para a equipe. Forneça uma indicação da prioridade de cada risco de qualidade iminente e use a prioridade para indicar a ordem de abordagem desses problemas.
7. Fazer uma avaliação de cobertura de teste: Com base no trabalho na etapa cobertura de execução do teste, forneça uma breve instrução resumida do status e das informações representadas pelos dados.
8. Fazer um rascunho do resumo de avaliação de testes: Apresentar os resultados do teste para este ciclo de testes em um sumário de avaliação de testes. Esta etapa desenvolve o rascunho inicial do sumário, realizado por meio da montagem das informações anteriores, reunidas em um relatório de sumário legível. Dependendo dos participantes e do contexto do projeto, o formato real e o conteúdo do sumário serão diferentes. Normalmente, é uma boa ideia distribuir o rascunho inicial a um subconjunto de investidores para obter um retorno que possa ser incorporado antes de divulgar para um público maior.
9. Avisar os investidores das descobertas chave: Publique essas informações usando qualquer método apropriado, recomenda-se que você divulgue-as em um site de projeto centralizado ou apresente-as nas frequentes reuniões de avaliação de status para que seja possível reunir feedback e determinar as próximas ações. Lembre-se de que disponibilizar publicamente os sumários de avaliação pode às vezes ser um problema político delicado. Negocie com o gerenciador de desenvolvimento para apresentar os resultados de uma maneira que eles reflitam um sumário honesto e preciso das suas descobertas, respeitando o trabalho dos desenvolvedores.
10. Avaliar e verificar os resultados: Agora que o trabalho foi concluído, convém certificar-se de que foi vantajoso, você deve avaliar se o trabalho é de qualidade adequada e se ele é completo o suficiente para ser útil aos membros da equipe que o utilizarão em seguida como entrada para o trabalho deles. Faça as pessoas que realizam as tarefas de recebimento de dados, que dependem do seu trabalho como entrada, participarem da revisão do trabalho temporário. Faça isso enquanto existir tempo disponível para tomar alguma ação para resolver os problemas delas. Você também deve avaliar o trabalho em relação aos principais produtos de trabalho de entrada para certificar-se de que eles foram representados de modo preciso e suficiente. Pode ser conveniente que o autor do produto de trabalho de entrada revise o seu trabalho nesse sentido.